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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 
3GPP TS 32.240 [1], which provides an umbrella for other charging management documents that specify 

• the content of the CDRs per domain and subsystem (offline charging); 

• the content of real-time charging events per domain / subsystem (online charging); 

• the functionality of online and offline charging for those domains and subsystems; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [1]. 

The present document specifies the LCS Offline and Online Charging description for the LCS domain, based on the 
functional stage 2 description of the LCS in 3GPP TS 23.071 [201]. This charging description includes the offline and 
online charging architecture and scenarios specific to the LCS, as well as the mapping of the common 3GPP 
architecture specified in TS 32.240 [1] onto the LCS domain. It further specifies the structure and content of the CDRs 
for offline charging and the charging events for online charging. The present document is related to other 3GPP 
charging TSs as follows: 

■ The common 3GPP charging architecture is specified in TS 32.240 [1]; 

■ The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

■ A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

■ The file based mechanism used to transfer the CDRs from the network to the operator"s billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

■ The 3GPP Diameter application that is used for LCS domain offline and online charging is specified in 
TS 32.299 [50]. 

All terms, definitions and abbreviations, used in the present document, that are common across 3GPP TSs, are defined 
in 3GPP TR 21.905 [100]. Those that are common across charging management in GSM/UMTS domains, services, or 
subsystems are provided in the umbrella document 3GPP TS 32.240 [1] and are copied into clause 3 of the present 
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in 
the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22.1 15 [102]. 



References 



The following documents contain provisions, which through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions defined in 3GPP TR 21.905 [100] and 
3GPP TS 32.240 [1], and the following apply: 

accounting: process of apportioning charges between the Home Environment, Serving Network and Subscriber. 

billing: function whereby CDRs generated by the charging function(s) are transformed into bills requiring payment. 

Billing Domain: part of the operator network, which is outside the telecommunications network, that receives and 
processes CDR files from the network charging functions. It includes functions that can provide billing mediation and 
billing or other (e.g. statistical) end applications. It is only applicable to offline charging (see 'Online Charging System' 
for equivalent functionality in online charging). 

CDR field categories: the CDR fields are defined in the present document. They are divided into the following 
categories: 

• Mandatory (M): field that shall always be present in the CDR. 

• Conditional (C): field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory (0^): A field that operators have provisioned to always be included in the 
CDR. 

• Operator Provisionable: Conditional (O^): A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 

chargeable event: activity utilizing telecommunications network resources and related services for: 

■ user to user communication (e.g. a single call, a data communication session or a short message); or 

■ user to network communication (e.g. service profile administration); or 

■ inter-network communication (e.g. transferring calls, signalling, or short messages); or 

■ mobility (e.g. roaming or inter-system handover); and 

■ that the network operator may want to charge for. 

As a minimum, a chargeable event characterises the resource / service usage and indicates the identity of the involved 
end user(s). charging: a function within the telecommunications network and the associated OCS/BD components 
whereby information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it 
possible to determine usage for which the charged party may be billed. 

Charging Data Record (CDR): a formatted collection of information about a chargeable event (e.g. time of call set-up, 
duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be charged for 
parts of or all charges of a chargeable event a separate CDR shall be generated, i.e. more than one CDR may be 
generated for a single chargeable event, e.g. because of its long duration, or because more than one charged party is to 
be charged. 

charging event: a set of charging information forwarded by the CTF towards the CDF (offline charging) or towards the 
OCS (online charging). Each charging event matches exactly one chargeable event. 

charging function: entity inside the network domain, subsystem or service that is involved in charging for that domain, 
subsystem or service. 

circuit switched domain: domain within GSM / UMTS in which information is transferred in circuit switched mode. 
credit control: Editor's note: FFS. 

domain: part of a communication network that provides network resources using a certain bearer technology. 
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Fully Qualified Partial CDR (FQPC): partial CDR that contains a complete set of the fields specified in the present 
document. This includes all the mandatory and conditional fields as well as those fields that the PLMN operator has 
provisioned to be included in the CDR. The first Partial CDR shall be a Fully qualified Partial CDR. 

LCS Client: software and/or hardware entity that interacts with a LCS Server for the purpose of obtaining location 
information for one or more Mobile Stations 

LCS Clients subscribe to LCS in order to obtain location information. LCS Clients may or may not interact with human 
users. The LCS Client is responsible for formatting and presenting data and managing the user interface (dialogue). The 
LCS Client may reside in the Mobile Station (UE). 

LCS Server: software and/or hardware entity offering LCS capabilities. The LCS Server accepts requests, services 

requests, and sends back responses to the received requests 

The LCS server consists of LCS components, which are distributed to one or more PLMN and/or service provider. 

Location Based Service (LBS): service provided either by teleoperator or a 3"* party service provider that utilizes the 
available location information of the terminal 

Location Application offers the User Interface for the service. LBS is either a pull or a push type of service (see 
Location Dependent Services and Location Independent Services). In ETSI/GSM documentation of SoLSA, LBS is 
called "Location Related Service". ETSI and/or 3GPP -wide terminology harmonization is expected here. 

location estimate: geographic location of an UE and/or a valid Mobile Equipment (ME), expressed in latitude and 
longitude data 

The Location Estimate shall be represented in a well-defined universal format. Translation from this universal format to 
another geographic location system may be supported, although the details are considered outside the scope of the 
primitive services. 

middle tier (charging) TS: used for the 3GPP charging TSs that specify the domain / subsystem / service specific, 
online and offline, charging functionality. These are all the TSs in the numbering range from 3GPP TS 32.250 to 3GPP 
TS 32.279, e.g. 3GPP TS 32.250 [10] for the CS domain, or 3GPP TS 32.270 [30] for the MMS service. Currently, 
there is only one "tier 1" TS in 3GPP, which is TS 32.240 [1] that specifies the charging architecture and principles. 
Finally, there are a number of top tier TSs in the 32.29x numbering range ([50] ff) that specify common charging 
aspects such as parameter definitions, encoding rules, the common billing domain interface or common charging 
appUcations. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered. 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with bearer/session/service control is required. 

Online Charging System: Editor's note: FFS. 

packet switched domain: domain within GSM / UMTS in which data is transferred in packet switched mode. 
Corresponds to the term "GPRS". 

partial CDR: CDR that provides information on part of a subscriber session. A long session may be covered by several 
partial CDRs. Two formats are considered for Partial CDRs. One that contains all of the specified fields (FQPC); the 
second has a reduced format (RPC). 

Positioning method (/locating method): method or technical solution, which is used to get an estimate of the target 
mobile's geographical location 

EXAMPLE: Positioning methods based on radio cell coverage, GPS or Assisted GPS methods, which are based 
on the Time-Of- Arrival (TO A) algorithm, and OTDOA or E-OTD methods, which are based on 
the Time-Difference-Of- Arrival (TDOA) algorithm. The positioning methods are further described 
in UTRAN Stage 2, 3GPP TS 25.305 [203] and GERAN Stage 2, 3GPP TS 43.059 [204]. 

target UE: UE being positioned 

user: an entity, not part of the 3GPP System, that uses network resources by means of a subscription. The user may or 
may not be identical to the subscriber holding that subscription. 

User Equipment (UE): a device allowing a user access to network services. For the purpose of 3GPP specifications the 
interface between the UE and the network is the radio interface. A User Equipment can be subdivided into a number of 
domains, the domains being separated by reference points. Currently defined domains are the USIM and ME Domains. 
The ME Domain can farther be subdivided into several components showing the connectivity between multiple 
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functional groups. These groups can be implemented in one or more hardware devices. An example of such a 
connectivity is the TE - MX interface. Further, an occurrence of a User Equipment is an MS for GSM as defined in 
GSM TS 04.02. UE in the present document may also refer to a Mobile Equipment or User Equipment used for 
emergency calls, that do not have valid SIM or USIM. 



3.2 Symbols 

For the purposes of the present document, the following symbols apply: 



Bl 
Lr 



Reference point for the CDR file transfer from the GMLC CGF to the BD, 
Interface between Gateway MLCs 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations defined in 3GPP TR 21.905 [100], 3GPP TS 23.271 [20] 
and 3GPP TS 32.240 [1], and the following apply: 

3G 3'''^ Generation 

3GPP 3"' Generation Partnership Project 

AVP Attribute Value Pair 

BD Billing Domain 

CCA Credit Control Answer 

CCR Credit Control Request 

CDF Charging Data Function 

CDR Charging Data Records 

CGF Charging Gateway Function 

CS Circuit-Switched 

CTF Charging Trigger Function 

DCCA Diameter Credit Control Application 

ECUR Event Charging with Unit Reservation 

FT AM File Transfer, Access and Management 

GERAN GSM EDGE Radio Access Network 

GGSN Gateway GPRS Support Node 

GMLC Gateway MLC 

GPRS General Packet Radio Service 

GSM Global System for Mobile communication 

gsmSCF GSM Service Control Function 

H-GMLC Home GMLC 

HLR Home Location Register 

HPLMN Home PLMN 

HSS Home Subscriber Server 

lEC Immediate Event Charging 

IETF Internet Engineering Task Force 

IMS IP Multimedia Subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

ITU-T International Telecommunication Union - Telecommunications standardization sector 

LCS Location Service 

MAP Mobile Application Part 

ME Mobile Equipment 

MO Mobile Originated 

MO-LR Mobile Originated - Location Request 

MS Mobile Station 

MSISDN Mobile Station Integrated Services Data Network 

MT Mobile Terminated 

MT-LR Mobile Terminated - Location Request 

NI-LR Network Induced - Location Request 

OCS Online Charging System 

PLMN Public Land Mobile Network 

PMD Pseudonym Mediation Device functionality 
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PPR Privacy Profile Register 

PS Packet Switched 

RAN Radio Access Network 

R-GMLC Requesting - GMLC 

RPC Reduced Partial CDR 

SGSN Serving GPRS Support Node 

TR Technical Report 

TS Technical Specification 

UE User Equipment 

UMTS Universal Mobile Telecommunications System 

USIM User Service Identity Module 

UTRAN Universal Terrestrial Radio Access Network 

V-GMLC Visited GMLC 

VPLMN Visited PLMN 



4 Architecture considerations 

4.1 High level LCS architecture 

Figure 4. 1 depicts the logical LCS architecture, as described in3GPP TS 23.271 [201]. 
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Figure 4.1 : LCS logical architecture with inter-GMLC [Lr] interface 

As can be seen in figure 4.1, the following LCS elements are relevant for charging: 

- VGMLC, 

- HGMLC 

- RGMLC. 

Editor's note: Add a statement stating that the SGSN and the MSC have also a role in the LCS Charging and that the 
associated LCS Charging functionality is described in TS 32.250 and TS 32.251 
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4.2 LCS offline charging architecture 

As described in TS 32.240 [1], the CTF (an integrated component in each charging relevant NE) generates charging 
events and forwards them to the CDF. The CDF, in turn, generates CDRs which are then transferred to the CGF. 
Finally, the CGF creates CDR files and forwards them to the Billing Domain. 

In LCS, all charging functions (CTF, CDF and CGF) reside within the LCS R/S. I.e. the GMLC is connected direcdy to 
the Billing Domain via the Bl interface. Bl is the LCS specific variant of the common Bx interface. This architecture 
implies that there exists no separate CDF and CGF for LCS, i.e. no corresponding open interfaces between any such 
functions, within the 3GPP standards. 

Figure 4.2 depicts the mapping of the 3GPP common charging architecture, as laid down in 3GPP TS 32.240 [1], onto 
the LCS. 

Editor's note: A clarification for the LCS offline charging reference point is in discussion 



GMLC 



CDF/CGF 



Bl 



BD 



Figure 4.2: LCS offline charging architecture 

In addition to the standard approach depicted in figure 4.2, vendors may choose to implement separate CDF and CGF 
for LCS. In that case, the interfaces between these functions should comply with the definition of the Rf and Ga 
interfaces (3GPP TS 32.299 [50] and 3GPP TS 32.295 [54], respectively) as much as possible. 

4.3 LCS online charging architecture 

LCS online charging is based on GMLC functionality that is further specified in the present document. For online 
charging, the GMLC utilises the Ro interface and application towards the OCS as specified in TS 32.299 [50]. The Ro 
reference point covers all online charging functionality required for LCS. 

The LCS online charging architecture is depicted in figure 4.3. 



Online Charging System 



Figure 4.3: LCS online charging architecture 

Details on the interfaces and functions can be found in TS 32.240 [1] for the general architecture components, 
TS 32.296 [53] for the OCS, and TS 32.299 [50] for the Ro application. 
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LCS charging principles and scenarios 

Editor's note: Include a brief introduction statement saying that this clause contains the CDR and charging event 
types and their trigger conditions. 



5.1 LCS charging principles 



Charging information in the Service domain for LCS is collected for inter-operator charging purpose by the GMLC. 
The basic principle is that a network requesting location information may be charged by the network that provides the 
location information. 

The GMLC shall collect the following charging information: 

• Identity of the mobile subscriber to be located and of the entity requesting the location; 

• Identity of the GMLC or PLMN serving the LCS Ghent; 

• QoS Requested/Dehvered: the charging information shall describe the quality of the location requested and 
delivered to the LCS client; 

• Request Timestamp: the charging information shall record the date and time the location procedure was 
requested by the LCS client; 

• Location services requested: the charging information shall describe the service types for which the LCS client is 
allowed to locate the particular UE; 

• Usage of continuous/periodic tracking; 

• Charging for Location Based Services (LBS): the charging information shall describe the service specific 
information in addition to the above location resource information. 

The information listed above is captured for use cases in relation to: 

■ Mobile Originated Location Request; 

■ Mobile Terminated Location Request; 

■ Network Induced Location Request; 

Refer to TS 23.271 [201] for further details on the above LCS transactions. 



5.2 LCS offline charging scenarios 



5.2.1 Basic principles 

Editor's note: TBD. 

5.2.2 Rf message flows 

Not applicable, as the separation of the CTF and CDF is not in the scope of the LCS charging standards. Refer to clause 
4.2 for further information. 

Note: Vendors may nevertheless implement a separate CTF and CDF for LCS charging. In this case, it is recommended 
that the approach chosen conforms to the principles and protocol applications specified in TS 32.299 [50]. 

5.2.3 CDR Generation 

Editor's note: This section shall also include the triggers of the CDR generation, the CDR types 
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The flows described in the present document specify the charging communications between the GMLC and the billing 
function for different charging scenarios. The LCS related messages associated with these charging scenarios are shown 
primarily for general information and to illustrate the charging triggers. 

For the purpose of these examples, the following assumptions have been made: 

• that the RAN location procedures are not depicted; 

• that the CS and PS location procedures are not distinguished; 

• that the LCS client has no privacy override capability; 

• that the LCS charging procedures in the CS and the PS domains are not depicted 



5.2.3.1 



Mobile originated location request (MO-LR) 



Mobile Originated location request allows the UE to obtain its own geographical location or have its location 
information transferred to another LCS client. In this procedure, the R-GMLC, H-GMLC and V-GMLC are the same as 
no privacy checking is performed. 

Figure 5.2.3.1 illustrates a Mobile Originated Location Request that allows a UE to request its own location. 
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Figure 5.2.3.1 : Record trigger overview for lUIO-LR 

The MSC (or SGSN) receives a Location Service Invoke from the UE 

The MSC (or SGSN) forwards the Location result to the GMLC by sending a MAP Subscriber 

Location Report 

The GMLC transfers the location information to the LCS client. 

The LCS Client sends to the GMLC the Location Information ack message signalling the result. 

The GMLC acknowledges the MAP Subscriber Location Report and the associated MO-LR CDR 

is processed as specified in TS 32.297 [52]. 
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6. 



The MSC (or SGSN) returns a Service Response message to the UE carrying any location estimate 
requested by the UE 



The record trigger associated to the MO-LR is called 'LCS GMLC Mobile Originated' (LCS-GMO) 

5.2.3.2 Mobile terminated location request (MT-LR) 

Mobile terminated location request allows an external LCS client to ask for the location of a mobile subscriber (target 
UE). 

Figure 5.2.3.2 illustrates a Mobile Terminated Location Request scenario: 
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Figure 5.2.3.2: Record trigger overview for lUIT-LR 
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1 . The external LCS client requests the location of a target UE from the R-GMLC 

2. The R-GMLC requests the H-GMLC address by sending a MAP Send Routing Info for LCS 
message to the home HLR/HSS of the target UE to be located 

3. The HLR/HSS returns a MAP Send Routing Info for LCS ack message that contains the H-GMLC 
address 

4. The R-GMLC forwards the Location Service Request to the H-GMLC 

5. After performing privacy check, the H-GMLC requests the V-GMLC address by sending a MAP 
Send Routing Info for LCS message to the home HLR/HSS 

6. The HLR/HSS returns a MAP Send Routing Info for LCS ack message that contains the V-GMLC 
address 

7. The H-GMLC forwards the Location Service Request to the V-GMLC 

8. The V-GMLC forwards the Location request to the MSC or SGSN by sending a MAP Provider 
Subscriber Location Report 

9. After either a CS-MT-LR or PS-MT-LR was processed, the MSC or SGSN sends the 
acknowledgement of the MAP Provider Subscriber Location Report 

The associated LCS VGMT CDR is processed as specified in TS 32.297 [52] 

10. The V-GMLC sends the location service response to the H-GMLC. After the H-GMLC has 
performed privacy check, the associated LCS HGMT CDR is processed as specified in TS 32.297 
[52] 

1 1 . The H-GMLC sends the location service response to the R-GMLC and the associated LCS RGMT 
CDR is processed as specified in TS 32.297 [52]. 

12. The R-GMLC returns a Service Response message to the LCS client carrying any location 
estimate requested by the LCS client 
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5.2.3.3 Network induced location request (NI-LR) 

Network induced location request allows positioning for an emergency service call. 
Figure 5.2.3.3 illustrates a Network Induced Location Request scenario: 
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Figure 5.2.3.3: Record trigger overview for NI-LR 

1 . An emergency call procedure is initiated between the UE and the LCS client 

2. Positioning procedures are instigated 

3. The MSC (or SGSN) forwards the Location request to the GMLC by sending a MAP Subscriber 
Location Report 

4. The GMLC acknowledges the MAP Subscriber Location Report 

5. The GMLC transfers the location information to the LCS client and the associated LCS-GNI-CDR 
is processed as specified in TS 32.297 [52]. 

6. At some later time, the emergency services call is released. 

5.2.4 Ga record transfer flows 

Not applicable, as the separation of the CDF and CGF is not in the scope of the LCS charging standards. Refer to clause 
4.3 for further information. 

NOTE: Vendors may nevertheless implement a separate CDF and CGF for LCS charging. In this case, it is 

recommended that the approach chosen conforms to the principles and protocol applications specified in 
TS 32.295 [54]. 
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5.2.5 Bl CDR file transfer 

The integrated CGF of the GMLC transfers the CDR files to the BD as described in TS 32.297 [52]. In LCS, both fully 
qualified partial CDRs (FQPC) and reduced partial CDRs (RFC), as specified in TS 32.240 [1] may be supported on the 
Bl interface. In line with TS 32.240 [13], the support of FQPCs is mandatory, the support of RPCs is optional. For 
further details on the Bl protocol application refer to TS 32.297 [52]. 

5.3 LCS online charging scenarios 

LCS online charging uses the credit control application as specified in TS 32.299 [50]. 

5.3.1 Basic principles 

Editors Note: This section should be updated and aligned with 32.299. Some of this text will go into 32.299 and 
removed from this TS. 

Two cases for online charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR). 

In the case of Immediate Event Charging (lEC), granting units to the GMLC is performed in a single operation that also 
includes the deduction of the corresponding monetary units from the subscriber's account. The charging process is 
controlled by the corresponding credit control request which is sent for a given credit control event. 

In contrast. Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving units and 
releasing and returning unused units. The deduction of the corresponding monetary units then occurs upon conclusion 
of the ECUR transaction. In this case, the credit control request is used to control the credit control session. 

The GMLC may apply either lEC, where CCR Event messages are generated, or ECUR, using CCR Initial, Termination 
and Update. The decision whether to apply lEC or ECUR is based on the service and/or operator's policy. 

NOTE: To the extent possible alignment with IETF RFC 4006 [402] is planned. 

Editor's note: Modify the text above with LCS specific description on what the GMLC requests from the ECF 
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5.3.2 Ro message flows 



The message flows described in the present document specify the charging communications between the GMLC and the 
Online Charging System (OCS) for different charging scenarios. The LCS messages associated with these charging 
scenarios are shown primarily for general information and to illustrate the charging triggers that are also used for LCS 
offline charging. 



5.3.2.1 



Mobile originated Location Request (MO-LR) 



Figure 5.3.2.1 shows the credit control transactions that are required between GMLC and OCS during the mobile 
originated location request. In this scenario the UE is the party to charge for the location request. 
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Figure 5.3.2.1 : LCS Online charging scenario for MO-LR 



£75/ 



3GPP TS 32.271 version 9.0.0 Release 9 



19 



ETSI TS 132 271 V9.0.0 (2010-02) 



5.3.2.2 Mobile Terminated Location Request (MT-LR) 

Figure 5.3.2.2 shows the credit control transactions that are required between GMLC and OCS during the mobile 
terminated location request. 
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Figure 5.3.2.2: LCS Online charging scenario for MT-LR 
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Definition of charging information 



This clause provides Stage 3 specifications of the CDR type and content in line with the CDR type definitions provided 
in clause 5.2.3 and Diameter Credit Control messages for LCS 

6.1 Data description for LCS offline charging 

Dedicated types of CDRs can be generated for LCS by the GMLC. The content of each CDR type is defined in one of 
the tables that are part of this clause. For each CDR type the parameter definition includes the parameter name, 
description and category. 

Equipment vendors shall be able to provide all of the parameters listed in the CDR content table in order to claim 
compliance with the present document. However, since CDR processing and transport consume network resources, 
operators may opt to eliminate some of the parameters that are not essential for their operation. This operator 
provisionable reduction is specified by the parameter category. 



A parameter category can have one of two primary values: 



M This parameter is Mandatory and shall always be present in the Diameter messages/CDR. 

C This parameter shall be present in the Diameter message/CDR only when certain Conditions are met. These 
Conditions are specified as part of the parameter definition. 

Some of these parameters are designated as Operator provisionable (O). Using TMN management functions or specific 
tools provided by an equipment vendor, operators may choose to include or omit the parameter from the charging 
event/CDR. Once omitted, this parameter is not generated in a CDR of the particular type.. To avoid any potential 
ambiguity, the CTF/CDF/CGF MUST be able to provide all these parameters. Only an operator can choose whether or 
not these parameters should be generated in its system, i.e. included in the charging Diameter message/CDR. 

Those parameters that the operator configures to be present or absent are further qualified with the "Operator 
provisionable" indicator as follows: 

Om This is a parameter that, if provisioned by the operator to be present, shall always be included in the Diameter 
messages/CDRs. In other words, an Oj^parameter that is provisioned to be present is a mandatory parameter. 

Oj. This is a parameter that, if provisioned by the operator to be present, shall be included in the Diameter 

messages/CDRs when the specified conditions are met. In other words, an O^ parameter that is configured to 
be present is a conditional parameter. 

The GMLC's CGF shall be able to provide the CDRs at the Billing System interface in the format and encoding 
described in the present document. In LCS, both fully qualified partial CDRs (FQPC) and reduced partial CDRs (RPC), 
as specified in TS 32.240 [1] may be supported on the Bl interface. In line with TS 32.240 [13], the support of FQPCs is 
mandatory, the support of RPCs is optional. 

6.1 .1 Ro message contents 

Not applicable. Refer to subclause 5.2.2 for further information. 

6.1 .2 Ga message contents 

Not applicable. Refer to subclause 5.2.3 for further information. 

6.1 .3 CDR description on tine Bl interface 

This clause provides Stage 3 specifications of the CDR type and content for the 3GPP LCS domain. For each of the 
CDR types, a parameter table, which gives a short description of the parameters, is provided. The detailed specification 
of the CDR parameters and their encoding is contained in TS 32.298 [51], while TS 32.297 [52] specify the details of 
the CDR file transfer to the BD. 
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6.1.3.1 



LCS Records for Mobile Originated Location Request (LCS-G MO-CD R) 



If enabled, a LCS GMLC Mobile originated Charging Data Record (LCS-GMO-CDR) shall be produced for each 
mobile originated location request performed via the GMLC. The fields in the record are specified in table 6.1.3.1, 
which provides a brief description of each field. 

Table 6.1.3.1: LCS GMLC Mobile Originated CDR (LCS-GMO-CDR) 



Field 


Category 


Description 


Record Type 


M 


LCS GMLC Mobile Originated Record 


Recording Entity 


M 


The E.1 64 address of this GMLC 


LCS Client Type 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


C 


Further identification of the LCS client, if available. 


Served IMSI 


M 


The IMSI of the subscriber that requests the location. 


Served MSISDN 


Om 


The primary MSISDN of the subscriber that requests the location. 


Serving Entity 


C 


The E.1 64 address of the serving MSC (in case of CS-MO-LR) or SGSN (in 
case of PS-MO-LR) 


Location Estimate 


Oc 


The location estimate for the subscriber if contained in geographic position and 
the LR was successful. 


Positioning Data 


c 


The positioning method used or attempted, if available. 


User Error 


c 


The Location Service type of error if any failure happened 


Provider Error 


Oc 


The protocol related type of error if any failure happened 


Record Time Stamp 


Om 


Time of generation of the CDR 


Local Record Sequence 
Number 


Om 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 


Record extensions 


Oc 


A set of network/manufacturer specific extensions to the record. Conditioned 
upon the existence of an extension. 



6.1 .3.2 LCS RecorcJs for mobile terminated location request 
6.1 .3.2.1 LCS Records for Requesting GMLC (LCS-RGMT-CDR) 

If enabled, a LCS Requesting GMLC Mobile terminated Charging Data Record (LCS-RGMT-CDR) shall be produced 
for each mobile a terminated location request is performed via the R-GMLC. The fields in the record are specified in 
table 6.1.3.2.1, which provides a brief description of each field. 

Table 6.1 .3.2.1 : LCS Requesting GMLC Mobile Terminated CDR (LCS-RGMT-CDR) 



Field 


Category 


Description 


Record Type 


M 


LCS Requesting GMLC Mobile Terminated Record 


Recording Entity 


M 


The E.164 address of this GMLC 


Home GMLC Identity 


C 


If available, the IP address of the HGMLC involved in the location request 


LCS Client Type 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


C 


Further identification of the LCS client, if available. 


Target IMSI 


M 


The IMSI of the targeted LCS subscriber 


Target MSISDN 


Om 


The primary MSISDN of the targeted subscriber. 


Location Type 


M 


The type of location information being requested. 


LCS Priority 


C 


Priority of the LR, if available 


Result Code 


Om 


The result code that indicate the result of the request or individual positioning 


Record Time Stamp 


Om 


Time of generation of the CDR 


Local Record Sequence 
Number 


Om 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 


Record extensions 


Oc 


A set of network/manufacturer specific extensions to the record. Conditioned 
upon the existence of an extension. 
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6.1 .3.2.2 LCS Records for Home GMLC (LCS-HGMT-CDR) 

If enabled, a LCS Home GMLC Mobile terminated Charging Data Record (LCS-HGMT-CDR) shall be produced for 
each mobile a terminated location request is performed via the H-GMLC. The fields in the record are specified in table 
6.1.3.2.2, which provides a brief description of each field. 

Table 6.1.3.2.2: LCS Home GMLC Mobile Terminated CDR (LCS-HGMT-CDR) 



Field 


Category 


Description 


Record Type 


M 


LCS Home GMLC Mobile Terminated Record 


Recording Entity 


M 


The E.164 address of this GMLC 


Requesting GIVILC Identity 


C 


If available, the IP address of the RGMLC involved in the location request 


Visited GMLC Identity 


C 


If available, the IP address of the VGMLC involved in the location request 


Serving Networl< Identity 


Oc 


MCC and MNC of the serving network used during this record, if available. 


LCS Client Type 


c 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


c 


Further identification of the LCS client, if available. 


Target IMSI 


M 


The IMSI of the targeted LCS subscriber 


Target MSISDN 


Om 


The primary MSISDN of the targeted subscriber. 


Location Type 


M 


The type of location information being requested. 


LCS Priority 


C 


Priority of the LR, if available 


Result Code 


Om 


The result code that indicate the result of the request or individual positioning 


Record Time Stamp 


Om 


Time of generation of the CDR 


Local Record Sequence 
Number 


Om 


Consecutive record number created by this node. The number Is allocated 
sequentially including all CDR types. 


Record extensions 


Oc 


A set of network/manufacturer specific extensions to the record. Conditioned 
upon the existence of an extension. 



6.1 .3.2.3 LCS Records for Visited GMLC (LCS-VGMT-CDR) 

If enabled, a LCS Visited GMLC Mobile terminated Charging Data Record (LCS-VGMT-CDR) shall be produced for 
each mobile a terminated location request is performed via the V-GMLC. The fields in the record are specified in table 
6. 1 .3.2.3, which provides a brief description of each field. 

Table 6.1.3.2.3: LCS Visited GMLC Mobile Terminated CDR (LCS-VGMT-CDR) 



Field 


Category 


Description 


Record Type 


M 


LCS Visited GMLC Mobile Terminated Record 


Recording Entity 


M 


The E.1 64 address of this GMLC 


Home GMLC Identity 


C 


If available, the IP address of the HGMLC involved in the location request 


LCS Client Type 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


c 


Further identification of the LCS client, if available. 


Target IMSI 


M 


The IMSI of the targeted LCS subscriber 


Target MSISDN 


Om 


The primary MSISDN of the targeted subscriber. 


Location Type 


M 


The type of location information being requested. 


LCS Priority 


C 


Priority of the LR, if available 


Result Code 


Om 


The result code that indicate the result of the request or individual positioning 


Record Time Stamp 


Om 


Time of generation of the CDR 


Local Record Sequence 
Number 


Om 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 


Record extensions 


Oc 


A set of network/manufacturer specific extensions to the record. Conditioned 
upon the existence of an extension. 
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6.1.3.3 



LCS Records for Network Initiated Location Request (LCS-GNI-CDR) 



If enabled, a LCS GMLC Network Induced Charging Data Record (LCS-GNI-CDR) shall be produced for each 
network induced location request performed via the GMLC. The fields in the record are specified in table 6.1.3.3, which 
provides a brief description of each field. 

Table 6.1.3.3: LCS GMLC Network Induced CDR (LCS-GNI-CDR) 



Field 


Category 


Description 


Record Type 


M 


LCS GMLC Network Induced Record 


Recording Entity 


M 


The E.I 64 address of this GIVILC 


LCS Client Type 


C 


The type of the LCS client that invoked the LR, if available. 


LCS Client Identity 


C 


Further identification of the LCS client, if available. 


Served IMSI 


M 


The IIVISI of the subscriber that requests the location. 


Served MSISDN 


Om 


The primary MSISDN of the subscriber that requests the location. 


Serving Entity 


c 


The E.164 address of the serving MSC (in case of CS-NI-LR) or SGSN (in case 
of PS-NI-LR) 


Result Code 


Om 


The result code that indicate the result of the request or individual positioning 


Record Time Stamp 


Om 


Time of generation of the CDR 


Local Record Sequence 
Number 


Om 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 


Record extensions 


Oc 


A set of network/manufacturer specific extensions to the record. Conditioned 
upon the existence of an extension. 



6.2 Data description for LCS online charging 
6.2.1 Ro message contents 

The credit control request for the "interim interrogation" and "final interrogation" reports the actual number of "units" 
that were used, from what was previously reserved. This determines the actual amount debited from the subscriber's 
account. 

Editor's note: The content above is FFS 

Table 6.2.1 describes the use of these messages for online charging. 

Table 6.2.1 : Online Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Abbreviation 


Credit-Control-Request 


GMLC 


OCS 


CCR 


Credit-Control-Answer 


OCS 


GMLC 


CCA 
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6.2.1.1 



LCS Credit-Control-Request Message 



Table 6.2.1.1 illustrates the basic structure of a Diameter credit control request message from GMLC as used for LCS 
online charging. 

Table 6.2.1.1 : Credit-Control-Request (CCR) Message Contents for LCS 



AVP 


Category 


Description 


Session-Id 


M 


Described in RFC 3588, diameter base protocol [401] 


Origin-Host 


M 


Described in RFC 3588, diameter base protocol [401] 


Origin-Realm 


M 


Described in RFC 3588, diameter base protocol [401] 


Destination-Realm 


M 


Described in RFC 3588, diameter base protocol [401] 


Auth-Application-ld 


M 


Described in RFC 3588, diameter base protocol [401] 


Destination-Host 


Oc 


Described in RFC 3588, diameter base protocol [401] 


User-Name 


Oc 


Described in RFC 3588, diameter base protocol [401] 


Origin-State-Id 


Oo 


Described in RFC 3588, diameter base protocol [401] 


Event-Timestamp 


Oc 


Described in RFC 3588, diameter base protocol [401] 


CC-Request-Type 


M 


Described in Internet-Draft, Diameter Credit Control Application [402] 


CC-Request-Number 


M 


Described in Internet-Draft, Diameter Credit Control Application [402] 


CC-Sub-Session-ld 


M 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Acct-Multi-Session-ld 


? 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Subscription-Id 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Service-Identifier 


? 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Termination-Cause 


? 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Requested-Service-Unit 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Requested-Action 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Used-Service-Unit 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


IVIultiple-Services-lndicator 


Om 


Described in Internet-Draft, Diameter Credit Control Application [402] 


IVIultiple-Services-Credit Control 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


Service-Parameter-Info 


Oc 


Described in Internet-Draft, Diameter Credit Control Application [402] 


CC-Correlation-ld 


? 


Described in Internet-Draft, Diameter Credit Control Application [402] 


User-Equipment-Info 


? 


Described in Internet-Draft, Diameter Credit Control Application [402] 


3GPP Diameter Credit Control AVPs | 


LCS-lnformation 


Oc 


This AVP holds the LCS service specific parameters. It is further 
described in the table below 



NOTE: A full description and the detailed use of the AVPs for GMLC and for each CCR request type 
(initial/update/termination/event) is specified in TS 32.299 [50]. 

The LCS-lnformation AVP contains the following sup-parameters: 



LCS Client Type 



Oc 



This AVP holds the type of the LCS client that invoked the LR, if available. 



LCS Identity 



Oc 



This AVP holds further identification of the LCS client, if available. 



Location Type 



Oc 



This AVP holds the type of location information being requested in case of MT-LR 



Editor's note: The table above should indicate which generic AVP is relevant for LCS based on 32.299 
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6.2.1.2 



LCS Credit-Control-Answer Message 



Table 6.2.1.2 illustrates the basic structure of a Diameter credit control answer message as used for LCS charging. This 
message is always used by the OCS as specified below, independent of the receiving GMLC and the CCR request type 
that is being replied to. 

Table 6.2.1.2: Credit-Control-Answer (CCA) Message Contents for LCS 



AVP 


Category 


Description 


Session-Id 


M 


Described in RFC 3588, diameter base protocol [401] 


Result-Code 


M 


Described in RFC 3588, diameter base protocol [401] 


Origin-Host 


M 


Described in RFC 3588, diameter base protocol [401] 


Origin-Realm 


M 


Described in RFC 3588, diameter base protocol [401] 


Auth-Application-ld 


M 


Described in RFC 3588, diameter base protocol [401] 


User-Name 


Oc 


Described in RFC 3588, diameter base protocol [401] 


Origin-State-Id 


Oc 


Described in RFC 3588, diameter base protocol [401] 


Event-Timestamp 


0. 


Described in RFC 3588, diameter base protocol [401] 


CC-Request-Type 


M 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


CC-Request-Number 


M 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


CC-Session-Failover 


? 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


CC-Sub-Session-ld 


M 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Acct-Multi-Session-ld 


? 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Subscription-Id 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Granted-Service-Unit 


7 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


IVIultiple-Services-Credit Control 


0. 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Cost-Information 


0. 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Final-Unit-lndication 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Check-Balance-Result 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Credit-Control-Failure-Handling 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Direct-Debiting-Failure-Handling 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Validity-Time 


Oc 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Redirect-Host AVP 


7 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Redirect-Host-Usage 


7 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


Redirect-IVIax-Cache-Time 


7 


Described in Internet-Draft 


Diameter Credit Control Application [402] 


3GPP Diameter Credit Control AVPs | 









Editor's note: The table above should indicate which generic AVP is relevant for LCS based on 32.299. 
Editor"s note: The description of the AVPs should be replaced by the LCS specific usage description. 
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